Subject: Comments on cisco's scalability proposal

From: David Bryant/HQ/3Com <[email-masked]>
Date: 11 Jul 95 11:05:27 EDT

I've read through the cisco proposal and have the following significant 
questions/comments:

1). The proposal as currently submitted is clearly too ambiguous to understand 
precisely what is being proposed.  Many sections contain options and choices 
which would alter other areas.  So the proposal as it stands does not provide a 
self-consistent description of the modified protocol. 

2). The proposal does not adequately address the issues of "base and towers".  
Which portions of the proposal are mandatory and which portions are optional?  
Which functions have dependencies on other functions?

3). Interoperation with RFC 1795 nodes is not well addressed.  It is not clear 
that this proposal will work in the presence of RFC 1795 nodes.  This 
interrelationship must be further defined and all restrictions duly noted.  
Additionally, it should be a design objective to accomodate easy migration from 
RFC 1795 networks to DLSw networks with scalability enhancements.  It's not 
clear (one way or the other) whether the Border Peers proposal can do this.

4). Handling POD Peers:  
It is not viable to select option 2 in which POD peers list the resources they 
can reach in the capabilities exchange with the exclusive flag.  The nature of 
stations available on a LAN will change over time and POD peers will not be 
able to relay this changed information.

5). Backup Peers
I do not favor bringing down SSP-SSP connections when live circuits exist.  It 
will also be difficult to address traffic which does not flow on circuits such 
as NetBIOS datagrams and perhaps HPR traffic in the future.  The proposal does 
not specify which SSP is responsible for bringing down the backup SSP-SSP 
connection.

6). Peer Costs
It's not clear to me the distinction between: "peer costs", "peer connection 
costs", and "path costs"
Use of this cost notion is also likely to effect the CANUREACH/ICANREACH 
protocols as it will likely be important to wait for all responses prior to 
choosing an SSP connection path for circuit setup.  And since the 
CANUREACH/ICANREACH protocol does not have the concept of a negative response 
(ICANTREACH), this introduces further complexities in resolving circuit setup 
to the appropriate SSP connection.

7). Peer Groups & Border Peers
It appears as though a Border Peer cannot have connections to an RFC 1795 (or 
prior) node.
Use of multicasting introduces further migration complications in requiring all 
nodes to support IP multicasting of the same type (MOSPF, DVMRP, etc.).  

8). Peer on Demand
Delays in SSP-SSP connection setup are very likely to cause problems with 
NetBIOS communications which are very time delay sensitive.  This may 
effectively negate the use of Peer on Demand in NetBIOS networks which is the 
primary environment for the Border Peer proposal (meshed SSP networks).

9). Non-Meshed networks
The proposal does not do anything to reduce TCP/IP overhead associated with 
configurations where many DLSw LANs must access a single data center.  This is 
the most common SNA configuration and as such deserves some measure of 
attention. 

David Bryant
3Com Corp